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Abstract 

Functional reactive programming (FRP) is an elegant approach 
to declaratively specify reactive systems. However, the powerful 
abstractions of FRP have historically made it difficult to predict and 
control the resource usage of programs written in this style. 

In this paper, we give a new language for higher-order reactive 
programming. Our language generalizes and simplifies prior type 
systems for reactive programming, by supporting the use of streams 
of streams, first-class functions, and higher-order operations. We 
also support many temporal operations beyond streams, such as 
terminatable streams, events, and even resumptions with first-class 
schedulers. Furthermore, our language supports an efficient imple¬ 
mentation strategy permitting us to eagerly deallocate old values and 
statically rule out spacetime leaks, a notorious source of inefficiency 
in reactive programs. Furthermore, these memory guarantees are 
achieved without the use of a complex substructural type discipline. 

We also show that our implementation strategy of eager deallo¬ 
cation is safe, by showing the soundness of our type system with a 
novel step-indexed Kripke logical relation. 

Categories and Subject Descriptors D.3.2 [Dataflow Languages ] 

Keywords Functional reactive programming; Kripke logical re¬ 
lations; temporal logic; guarded recursion; dataflow; capabilities; 
comonads 

1. Introduction 

Interactive programs engage in an ongoing dialogue with the envi¬ 
ronment. An interactive program receives an input event from the 
environment, and computes an output event, and then waits for the 
next input, which may in turn be affected by the earlier outputs the 
program has made. Examples of such systems range from embedded 
controllers and sensor networks, up to graphical user interfaces, web 
applications, and video games. 

Programming interactive applications in general purpose pro¬ 
gramming languages can be very confusing, since the different 
components of the program do not typically interact via structured 
control flow (such as loops or direct procedure calls), but instead 
operate by registering state-manipulating callbacks with one another, 
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which are then implicitly invoked by an event loop. Reasoning about 
such programs is difficult, since each of these features - higher-order 
functions, aliased imperative state, and concurrency - is challenging 
on its own, and their combination takes us to the outer limits of what 
verification can cope with. 

These difficulties, plus the critical nature of many reactive 
systems, have inspired a great deal of research into languages, 
libraries and analysis techniques for reactive programming. Two 
of the main strands of work on this problem are the synchronous 
dataflow languages, and functional reactive programming. 

Synchronous dataflow languages, such Esterel [5], Lustre [7], 
and Lucid Synchrone [39], implement a computational model 
inspired by Kahn networks. Programs are fixed networks of stream¬ 
processing nodes that communicate with each other, each node 
consuming and producing a statically-known number of primitive 
values at each clock tick. These languages deliver strong guarantees 
on space and time usage, and so see wide use in applications such 
as hardware synthesis and embedded control software. 

Functional reactive programming, introduced by Elliott and 
Hudak [15], also works with time-varying values (rather than 
mutable state) as a primitive abstraction. However, it provides a 
much richer model than synchronous languages do. Signals are 
first-class values, and can be used freely, including in higher-order 
functions and signal-valued signals, which permits writing programs 
which dynamically grow and alter the dataflow network. FRP has 
been applied to problem domains such as robotics, games, music, 
and GUIs, illustrating the power of the FRP model. 

However, this power comes at a steep price. Modeling A-valued 
signals as streams A w (in the real-valued case, A R ) and reactive 
systems as functions lnput tu —» Output^ has several problems. 
First, this model does not enforce causality (that is, output at time 
n depends only upon inputs at earlier times), nor does it ensure 
that feedback (used to define signals recursively) is well-founded. 
Second, since the model of FRP abstracts away from resource 
usage, it is easy to write programs with significant resource leaks 
by inadvertently accumulating the entire history of a signal - that 
is,“space leaks”. 1 For example, consider the simple program below: 
bad_const : SN —» S(SN) 1 

bad_const ns = consfns, bad_const ns) 2 

The bad .const function takes a stream of numbers as an argument, 
and then returns that stream constantly. So if it receives the stream 
(a, b, c,...), then it returns a stream of streams with (a, b, c,...) as 
its first element, with (a, b, c,...) as its second element, and so on 


1 In reactive programming, the phrase “space leak” usually refers only to 
memory leaks arising from capturing too much history, since they form 
the species of memory leak that functional programmers are unused to 
debugging. Relatedly, there are also “time leaks”, which occur when a signal 
is sampled infrequently. Under lazy evaluation, infrequent sampling can lead 
to the head of a stream growing to become a large computation. 





indefinitely. This is a perfectly natural, even boring, mathematical 
function on streams, but many implementations leak memory. Con¬ 
sider the following diagram, illustrating how a stream data structure 
evolves over time: 
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t-2 Q © Ql © © - 

t-3 Q © 0 © © - 

Here, a stream is a computation incrementally producing values. 
At time 0, the stream yields the value “a”, and at time 1, it yields 
the value “b”, and so on. Each value in a double-circle represents 
the stream’s current value at time t, and the values in white circles 
represent the stream’s future values , and the values in gray circles 
represent the stream’s past values. (So there are n gray circles at 

If a pointer to the head of a stream persists, then at time n all 
of the first n + 1 values of the stream will be accessible, and so 
we will need to store all the values the stream has produced - all 
of the grey nodes, plus the double-circled node. Thus, at time n, 
we will have to store n elements of history, which means that the 
memory usage of the bad .const function will be O(n) at time n. 
So the accidental use of a function like bad const in a long-running 
program will eventually consume all of the memory available. 

To avoid this problem, a number of alternative designs, such 
as such as event-driven FRP [43] and arrowized FRP [35], have 
been proposed. The common thread in this work is to give up on 
treating signals as first-class values, and instead offer a collection 
of combinators to construct stream transformer functions (that is, 
functions of type S A —» S B) from smaller ones. Streams of streams 
(and other time-dependent values) are forbidden, and each of the 
exported combinators is designed to ensure that only efficient stream 
transformers can be constructed. 

Restricting programmers to indirect access to streams is akin 
to a first-order programming style, since it makes it difficult to 
abstract over stream-manipulating operations. This restriction is 
also quite similar to those synchronous dataflow languages impose, 
and Liu et al. [30] exploit this resemblance to develop a compilation 
scheme (reminiscent of the Bohm-Jacopini theorem) to compile 
arrow programs into efficient single-loop code, much as compilers 
for Esterel and Lucid do. Sculthorpe and Nilsson [40] extend the 
arrowized approach further, by using dependent types to enforce 
causality. 

However, dynamic modification of the dataflow graph is very 
natural for interactive programs. For example, in a graphical pro¬ 
gram, we may wish to associate dataflow networks with windows, 
which are created and destroyed as a program executes. To support 
this, arrowized FRP libraries need to add additional combinators to 
restore dynamic behavior. These combinators make unwanted mem¬ 
ory leaks possible once more (though less easily than in the original 
FRP). They also have a somewhat ad-hoc flavor: since first-class 
and higher-order stream types are unavailable, somewhat complex 
and strange types are needed to encode typical usage patterns. 

To recover a more natural programming style, Krishnaswami and 
Benton [27] proposed a lambda-calculus for stream programming 
based on the guarded recursion calculus of Nakano [34], which 
ensured by typing that all definitions are causal and well-founded. 
Jeffrey [19] and Jeltsch [22] further observed that it is possible to 
use the formulas of linear temporal logic [38] as types for reactive 


programs. However, while all of these papers offer a coherent 
account of causality (not using values from the future, and ensuring 
that all recursive definitions are guarded), none of them have much 
to say about the memory behavior of their programs. 

To resolve this problem, Krishnaswami et al. [28] gave a calculus 
which retains the causality checking and fully higher order style of 
[19, 22, 27], but which also uses linear types to control the memory 
usage of reactive programs. This calculus passes around linearly- 
typed tokens representing the right to allocate stream values, which 
ensures that no program can ever allocate a dataflow graph which is 
larger than the total number of permissions passed in. This solution 
works, but is too precise to be useful in practice. The exact size 
of the dataflow graph is revealed in a program’s type, and so even 
modest refactorings lead to massive changes in the type signature of 
program components. 

Contributions Our contributions are as follows: 

1. We give a new implementation strategy, described using oper¬ 
ational semantics, for higher-order reactive programming. Our 
semantics rules out space and time leaks by construction, mak¬ 
ing it impossible to write programs which accidentally retain 
temporal values over long periods of time. 

To accomplish this, we describe the semantics of reactive pro¬ 
grams with two operational semantics. The first semantics ex¬ 
plains how to evaluate program terms in the current clock tick, 
and the second is a “tick relation” for advancing the clock. 
Expressions in a reactive language can be divided into two 
classes, those which must be evaluated now, and those which 
must be evaluated later, on future clock ticks. We evaluate current 
expressions using a call-by-value strategy, and we suspend future 
expressions by placing them in mutable thunks on the heap, in a 
style reminiscent of call-by-need. Evaluating current expressions 
in a call-by-value style prevents time leaks, by making streams 
head-strict [42], 

Future expressions can only be evaluated in the future, and the 
tick relation describes how to advance the clock into the future. 
This semantics works by going through the heap of thunks, 
and forcing each expression scheduled for execution on the 
current time step. Furthermore, we achieve our goal of blocking 
space leaks through the simple but drastic measure of deleting 
all old values, thereby making it operationally impossible to 
accidentally retain a reference to a value past its lifetime. 

2. We give a simple type theory for a higher-order reactive pro¬ 
gramming language. 

Our type system generalizes earlier work on using temporal 
logic [19, 22, 27] to type reactive programs. Instead of using 
formulas of temporal logic as types, we take a standard simply- 
typed lambda calculus, and introduce a delay modality «A of 
terms of type A that can be evaluated “on the next tick of the 
clock”, and add to that the new notion of a temporal recursive 
type (la. A, which allows defining types which are recursive 
through time. 

This recursive type construct allows encoding all of the standard 
temporal operators as derived constructions within our calculus - 
streams, events, and even resumptions are all definable within 
our system, as are higher-order functions to construct and 
manipulate elements of these types. 

To retain control over space leaks, we simplify the work of 
Krishnaswami et al. [28] on using linear types to prevent space 
leaks in reactive systems. We introduce a new kind of type-based 
capability which grants the right to allocate memory, without 
having to enumerate the exact amount of memory used. As a 
result, we do not need the complexities of a substructural type 



system, and moreover we no longer reflect exact memory usage 
in types, which improves the modularity of reactive programs. 

3. We show that our type discipline is sound by means of a novel 
step-indexed Kripke logical relation. 

Deleting old values naturally raises the question of what happens 
if we accidentally reference a deleted value. Our logical relation 
lets us prove that no well-typed program will ever dereference 
a deallocated location, and that expressions whose types say 
they do not allocate memory, do not actually allocate memory. 
Furthermore, the logical relation shows that the expression 
relation is total for well-typed terms, despite the presence of 
a term-level fixed point. This demonstrates that we can only 
define well-founded and causal loop structures. 

Supplementary Material Full proofs of the main results in this 
paper, and statements and proofs of all the supporting lemmas, can 
be found in the accompanying technical report. 

2. Programming Language 

We begin with a description of our language design. We give 
the syntax of types, terms, and values in Figure 1, the syntax of 
contexts in Figure 2, and the typing rules in Figures 3, 4, and 5. 
The operational semantics of expressions is in Figure 6, and the 
semantics of advancing the clock is in Figure 7. 

Overview In a reactive language, an explicit notion of time is 
exposed to the programmer, and so we will need to extend the 
operational semantics to account for time, and then give a modified 
type system which properly reflects the semantics. 

Our operational semantics consists of two relations. The ex¬ 
pression relation (cr;e) fcr'jv) describes how to evaluate an 
expression within a single timestep. This relation, given in Figure 6, 
is a standard big-step, call-by-value operational semantics for a 
functional language with a store. As we will see, the use of a call- 
by-value semantics rules out time leaks, since they are inherently an 
artifact of lazy evaluation. 

However, the stores are not unrestricted heaps in the style 
of ML. Since reactive languages allow programmers to schedule 
when different expressions should be executed, there are program 
expressions which should not be executed right away. We put these 
expressions into a store, with the idea that the code stored in the heap 
will be evaluated later. In terms of reactive programming idioms, the 
store represents the dataflow graph of the program, which contains 
the nodes that will supply values on later ticks of the clock. In 
terms of functional programming idioms, the store implements lazy 
evaluation, in a variant of call-by-need where thunks are explicitly 
scheduled for later execution. 

To actually advance the clock, we give the tick relation ct cr', 
which describes (Figure 7) how the store cr is transformed into a 
store cr' when the clock ticks. As expected, our relation evaluates all 
of the computations scheduled for evaluation on the next tick. The 
tick semantics also makes space leaks impossible, by construction: 
brutally but expediently it deletes all values that are more than one 
tick old. 

It is now trivially the case that it is impossible to inadvertently 
store a history too long - but, at what price? Surprisingly, we can 
show that the price is low. We give a type discipline, which not only 
ensures that all well-typed programs are safe (in that they never 
try to access a deleted value), but which is also expressive, in that 
natural reactive programs (higher-order or not) are still well-typed. 

Since the passage of time is a central feature of our operational 
semantics, we introduce three temporal qualifiers, now, later, and 
stable, to explain when some expression is well-typed, and when 
a variable may be used. The now qualifier means “in the present 


time step”, the later qualifier means “on the next time step”, and the 
stable qualifier means “at any time step, present or future”. 

As a result, our typing judgment takes the form F h e : A q, 
where q is a qualifier. So the informal reading of the typing judgment 
is “under hypotheses T, the expression e has type A at time q.” lust 
as expressions have temporal qualifiers, so too do the hypotheses 
in the context. The context F (with a grammar given in Figure 2) 
consists of a list of hypotheses of the form x : A q, which gives 
not just a type A for each variable x, but also gives a qualifier q 
controlling when we may use the variable x. 

Types, Terms, and Expression Evaluation The core of our pro¬ 
gramming language is essentially the simply-typed lambda calculus. 
The basic types include product types A x B with pairs (e, e') and 
projections fst e and snd e, disjoint unions A + B with injections 
ini e and inre and a case statement case(e, inlx —> e',inry —> e"), 
and function types A —> B with lambda-abstractions Ax. e and appli¬ 
cations e e', as well as a variety of primitive types (such as numbers 
N and booleans bool). The typing rules for these constructs are all 
given in Figure 3, and are all standard. Similarly, the reduction rules 
for these terms are given in the first half of Figure 6, and are also 
standard. 

To this, we add a number of features to deal with time. 

First, we have the next-step operator «A. The intuitive reading 
of this type is that an inhabitant of • A is a term that, when evaluated 
on the next time step, will yield a value of type A - the type of “A’s 
tomorrow”. The introduction form is the delay term 5 e / (e), which 
says that e is a term to evaluate on the next time step. Consequently, 
its typing rule »I requires e to be typechecked later. The elimination 
form is a binding-style elimination form, let 6(x) = e in e'. The 
typing rule »E asserts that e is of type «A, and the variable x is of 
type A, but with the later qualifier. This ensures that the body e' 
does not use e’s value before it is available. 

Operationally, we do not evaluate the body e of a delayed 
expression 6 e /(e) right away. Instead, we extend the store with 
a pointer l : e later to a thunk e, which will be evaluated on the 
next time step. These pointers implement a form of call-by-need, 
ensuring that even if we use a delayed variable multiple times, the 
delayed expression will itself only be evaluated once. This can be 
seen in the reduction rule for let 6(x) = e in e'. Here, if e evaluates 
to the pointer l, the reduction rule substitutes !l, a dereferencing of 
the pointer, for x in e'. 

The allocation of a thunk extends the reactive program’s dataflow 
graph, and the growth of the dataflow graph is something we must 
control. To achieve this, we use the subscripted argument e' in 
the delay introduction form 6 e / (e). This argument must be of the 
allocation type alloc, and indicates a permission to allocate heap 
storage. Since the type alloc represents a pure capability [32], we 
have no introduction or elimination forms for it; a token (denoted 
by o in our syntax) representing this capability must be passed in 
to a closed program by the runtime system of the language. Thus, 
programmers may control whether or not a function allocates by 
controlling whether or not they pass it an allocation capability. 

Pointer expressions 1, dereference expressions !l, and resource 
tokens o are all internal forms of our language, and cannot be written 
by a programmer. (As a result, there are no typing rules for them.) 

Values of «A type are time-dependent, in the sense that their 
representation changes over time: when the clock ticks, the dataflow 
graph/store is evaluated, and pointers are updated. This means that 
they should only be used on particular time steps. Other types, 
such as natural numbers or booleans, consist of values whose 
representation does not change over time. These stable values may 
safely be used at many different times. Values of other types, such 
as functions A —> B, are either time-dependent or stable, depending 
on whether or not they capture any time-dependent values in their 
environment. 



So we also introduce a modal type DA, which contains only 
those values of type A which are stable. The introduction form 
stable(e) ensures that e has the type A under the stable qualifier, 
and the elimination form let stable(x) = e in e' takes a term e of 
type DA, and binds x to a stable variable. Since values of certain 
types (base types, and products and sums of same) are always stable, 
we also introduce a term promote(e), which takes a term of an 
inherently stable type A (as judged by the judgment A stable, 
defined in Figure 5) and returns a value of type □ A. 

In order to get interesting temporal data structures, we introduce 
a temporal recursive type, (la. A. This type has the expected 
introduction into e and elimination out e forms, but their types are 
slightly nonstandard. When constructing a term into e of recursive 
type (la. A, we require e to have the type [•(’(la. A)/a]A. That is, 
every occurrence of a in A is substituted with •((la. A), which is 
the recursive type on the next time step. This lets us use the next-step 
modality to define data whose structure repeats over time, rather 
than proceeding only a constant number of steps into the future. 

In addition to type-level recursion, we also have a term-level 
recursion operator fix x. e. There are no restrictions on the types we 
may take fixed points at; we only require that if fixx. e is of type A, 
then we assume x is a later variable. This ensures that we can never 
construct an unguarded loop. 

We also include a stream type S A, with an introduction form 
cons(e, e') and an elimination form let cons(x, xs) = e in e'. 
The stream type can be encoded using the other constructs of the 
language (see Section 3.2), but we include it in order to give a more 
readable syntax to our examples. However, the cons(e, e') form 
does help illustrate why we chose a call-by-value evaluation strategy. 
Under call-by-value, the head of the stream e is always evaluated 
to a value. As a result, “time leaks” are impossible, since the head 
gets reduced to a value on every tick, and so it doesn’t matter how 
frequently a stream is sampled. 

Finally, the variable rule Hyp says that we can only use a variable 
now, if it is either stable, or if it is available now. Then, there are the 
TStable and TLater rules, which show how to derive terms with 
the stable and later qualifiers, in terms of the now qualifier. The 
key to this are the context-clearing operations defined in Figure 2. 
The r n context operation deletes every now and later hypothesis, 
ensuring that stable terms may only depend on stable variables. The 
T* operation takes a context, and deletes every hypothesis marked 
now, and changes every later hypothesis to now, ensuring that terms 
which are typechecked later (1) view the later variables as if they 
were available in the present, and (2) do not access any variables 
containing possibly out-of-date values. 

Dataflow Graphs The store cr is used to represent the dataflow 
graph of the program, and contains a collection of pointers, which 
can be viewed as the nodes in a dataflow graph. Each node is either 
a suspended expression 1: e later to be evaluated on the next tick 
of the clock, or points to a presently available value l: v now, or is 
undefined l: null and points to nothing. 

Advancing Time We give the tick relation a =)> a' in Figure 7, 
which explains how to advance time for a dataflow graph. 

If the dataflow graph a is empty, then of course the updated store 
is also empty. In order to evaluate a store a, l ; e later, we first 
update the rest of the dataflow graph cr to o', and then evaluate e 
in the result store cr' to a value v, updating the pointer to l: v now. 
However, when we see a store a, l : v now containing a value, 
we evaluate the store, but null out the pointer, setting it to l: null. 
Finally, once nulled out, null pointers stay nulled out. 

This feature of the operational semantics suffices to ensure that 
FRP-specific space leaks are impossible - because our dataflow 
graph never stores values for more than a single tick, it follows that 
values can never accumulate and build up into a memory leak. As a 


result, values in dataflow nodes can never persist in memory unless 
the programmer explicitly writes code to retain them. (Of course, 
all the memory leaks traditional to functional programming are still 
possible - we have simply ensured that reactivity has not added any 
new sources of leaks.) 

It is worth reiterating that it is the operational semantics, and not 
the type system, which ensures the absence of space leaks: because 
we delete everything old, it is simply impossible to remember the 
past unless the programmer explicitly writes the code to do so. The 
type system merely acts as a set of guard rails, ensuring that we do 
not accidentally follow any invalid pointers. 

Making dataflow nodes transient is a significant departure from 
existing imperative implementation strategies for FRP libraries, such 
as Scala.React [31] or Racket’s FrTime [9, 10], In these libraries, 
dataflow nodes are persistent, and last across many time steps, and 
clever heuristics are used to order updates. 

Abandoning this strategy pays many dividends. We have already 
observed that accidental space leaks are no longer possible, but there 
are also further practical benefits. A real implementation needs to 
garbage collect null nodes. Fortunately, the structure of our typing 
rules ensures that well-typed program terms never contain locations 
that outlive their tick, and as a result, the usual reachability heuristic 
of standard garbage collectors will work unchanged. 

In contrast, persistent dataflow nodes need to manage dependen¬ 
cies explicitly, and as a result, each dataflow cell knows both which 
cells it reads, and which cells read it. This bidirectional linkage 
means that if one cell is reachable, all cells are reachable, defeating 
garbage collection unless special (and often expensive) measures 
such as weak references are used. 

Complete Programs Finally, we need to say a word about what 
complete programs in our language are. Since we use an object- 
capability style to control the growth of the dataflow graph, a user 
program must be a function type, so that it can receive a capability 
as an argument. Furthermore, since alloc is not a stable type, we 
will need to supply a fresh capability on each tick. 

For this reason, we take user programs to be closed terms of type 
S alloc —> A. If e is such a term, then we will begin evaluation of 
the program with the call e (fixxs. cons(o, 6 0 (xs))). The term 
fixxs. cons(o, 6 0 (xs)) computes into a term which produces a 
stream yielding an allocation token o at each tick, but this term 
cannot itself be typed under our type system. Modeling the fact that 
the runtime system of the language possesses certain capabilities 
that user programs do not. 

As a result, our metatheory needs to be done in a “semantic” style, 
using a step-indexed Kripke logical relation, rather than showing 
soundness through the usual syntactic progress and preservation 
lemmas. 

3. Examples 

3.1 Stream Functions 

Basic Examples We begin with the constant function on streams. 
It takes a natural number as an input, and returns a constant stream 
of that number. 

const: S alloc —> N —> SN 1 

let cons(u, 5(us')} =us in 3 

let stable(x) = promote(n) in 4 

cons(x, 6 u (const us' x)) 5 

In this example, we have a function const which receives a 
stream of permissions us to allocate, and a number n on line 2. 
On line 3, we take the head and tail of the permission stream, with 
a pattern-matching-style nested delay elimination to bind us' to 
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::= b | AxB | A + B | A —> B 
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| fixx. e 
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1 l 1 o 

stable(v) | intov | cons(v,v A .) 
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: v now | ff, l:e later | a, l: null 

Figure 1. Syntax 

Qualifiers q :: 

= now | stable later 

Contexts F :: 

= • | r,x:Aq 

(■)• 

(T, x : A later)* 

= F*,x : A now 

(r,x: A stable) 

= F*,x: A stable 

(r,x : A now)* 

= F* 


= 

(Fx: A stable) 

= r D ,x: A stable 

(T, x : A later) n 

= r D 

(r,x : A now) D 

= r D 

Figure 2. Hypotheses, Contexts and Operations on Them 

| F I- e : A q | 

F h e : A now 

F h e' : B now 

FI- (e, e' 

: A x B now X 

T h e : A x B now 
rh fste: A now XLE 

F h e : A x B now 

F h snd e : B now XRL 

T h e : A now 

r h e : B now 

r h ini e : A + B now +L 

Th inre: A + B now +RI 

Fh e : 

A + B now 

F,x : A now h e' : C now 

F,y : B now h e" : C now 

case(e, inlx —> 

e 7 , inry —> e") : C now +E 

F, x : A no 

w h e : B now 

F h Ax. e 

: A —> B now ^ 

F h e : A —> B no 

w The': A now 

F i e e' : B now 



Figure 3. Standard Typing Rules 


Figure 5. Stability of Types 
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(g;inl e) JJ. (g';inlv) 
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,inry ->e"))4J.(g";v") 

(g;e) )J. (g';inrv) 

(g';[v/y]e") 4J- (g";v") 

(g;case(e, ini x —> e' 

,inry -4 e")) 4J- (g";v") 


(ff;ei) 4) (a';Ax. e)} 

(g'; e 2 ) 4- (a"; V2) (a"\ [v 2 /x]ei') 4J- (g'";v) 

(g;e 1 e2) JJ- (g'";v) 


a ==!> a' (a'; e) 4J- (g";v) l 0 dom(g") 
==!> • a, l: e later =#> g", l: v now 

g=>g' l ^ dom(g') g g' l ^ dom(g') 
g, l: v now =} g', l: null g, l: null =$ g', l: null 


Figure 7. Tick Semantics 

a later variable. On line 4, we make use of the fact that natural 
numbers are stable in order to rebind n to the stable variable x. This 
lets us refer to x in both the head and tail of the cons-cell on line 
5. The head of the cons cell is just x itself, and the tail is a delayed 
stream, which we may allocate since we have a permission u. 

Below, we give a summation function, which takes a stream of 
numbers and returns a stream containing the cumulative sum of 
the stream. To implement this, we introduce an auxiliary function 
sum_acc which stores the sum in an accumulator variable, and then 
call it with an initial sum of 0. 

sunuacc : S alloc —tSN—>N—>SN 1 

sum.acc us ns acc = 2 

letcons(u,5(us'))=usin 3 

let cons(n,6(ns')) = ns in 4 

let stable(x) = promote(n+ acc) in 5 

cons(x,6 u (sum_accus , ns'x)) 6 


(g;e') jj. (g';o) l 0 dom(g') 

(g;6 e /(e)> 4J- <(g , ,l: e later);l) 

(g;e) 4J. (g';l) (g ; ; [!l/x]e'). 4-(g";v) l: v now <= g 

(g; let 6(x) = e in e'} 4) (g";v) (g;!l) 4J- (g;v) 

(g;e) 4J. (g';v) (g; e) 4) (g'; intov) 

(g; into e) 4J- (g'; intov) (g;out e) 4J, (g';v). 

(g;eH(g';v) 

(g;stable(e)) 4) (g';stable(v)} 

(g;e)4(g';v) 

(g; promote(e)) 4) (g';stable(v)) 

(g;e) 4J- (g';stable(v)) (g';[v/x]e'} 4J- (g";v") 

(g; let stable(x) = e in e'} 4) (g'';v") 

(g; e) -U- (g';v) (g'i e ; ) ij- (g";v') 

(g;cons(e, c'i) 4 (g";cons(v, v')) 

(g;e) JJ. (g';cons(v,l)) (g'; [v/x,l/xs]e') JJ. (g";v") 
(g;let cons(x,xs) = e in e') JJ. (g";v") 

(g; [fixx. e/x]e) jj. (g';v) 

(g;fixx. e) i.'|g';v) 


Figure 6 . Expression Semantics 


sum : Salloc —> SN —» SN 7 

sum us ns = sunuacc us ns 0 8 

Higher-Order Stream Operations Our language permits the free 
use of streams of streams, as well as higher-order functions on 
streams. We illustrate this with a simple function which takes a 
stream, and returns the stream of successive tails of that stream. 


tails: Salloc —>SA—>S(SA) 1 

tails us xs = 2 

let cons(u, 5(us')) = us in 3 

let cons(x,6(xs')) = xs in 4 

cons(xs, 6 u (tails us'xs')) 5 

The higher-order map functional is definable as follows: 
map:Salloc—>D(A—>B)—>SA—>SB 1 

map us ft xs = 2 

let cons(u, 5(us')) =us in 3 

let cons(x, 6(xs')) = xs in 4 

let stable(f) = h in 5 

cons(f x, 6 u (map us' stable(f) xs')) 6 


Note that the map functional calls its argument function on every 
element of the input stream. As a result, we need to use the function 
at many different time steps, and so we need to give the functional 
argument the stable type D(A —> B) to ensure that we can safely 
use it both now and later. 

The fact that all computable streams are definable in our language 
is witnessed by giving the unfold operation, which shows that the 
universal property of streams is definable within the language. 


unfold : S alloc —> [H(X —> A x »X) —> X —> S A 1 

unfold us h.x= 2 

let cons(u, 6(us')) = us in 3 

let stable(f) = h. in 4 

let (a, 6(x')) = f x in 5 

cons(a, 6 u (unfold us' stable(f) x')) 6 



Dynamic Changes of Streams Switching behavior is directly 
programmable in our language. The swap function below takes 
a number n, and two streams xs and ys. It yields the same values 
as xs on the first n time steps, and afterward the same values as ys. 


swap : S alloc —>N—>SA—>SA—>SA 1 

swap us n xs ys = 2 

if u = 0 then 3 

ys 4 

else 5 

let cons(u, 6(us')) = us in 6 

let cons(x, 6(xs')) = xs in 7 

let cons(y, 6(ys')) = ys in 8 

let stable(m) = promote(n) in 9 

cons(x,6 u (swapus' (m-1) xs'ys')) 10 


What is interesting about this example is that there is nothing 
surprising about it: it is basically an ordinary functional program. 
Unlike many other approaches to reactive programming, we program 
conditional behavior with ordinary conditional control flow. 

3.2 Type Encodings 

Streams In order to make the examples more readable, we in¬ 
cluded streams as a primitive type in our language, but that is actu¬ 
ally unnecessary, since they are encodable using recursive types: 

S A = (la. A x a 

This encoding looks completely conventional, but because unfolding 
a recursive type requires guarding the recursive type with a delay 
modality before substituting, this type is isomorphic to: 

SA~ Ax .(Ax .(Ax ...)) 

From a logical perspective, the stream type S A corresponds to 
the “always” operator of temporal logic, which asserts that at every 
time step, we always have a witness to the proposition A. 

Events In reactive programs, there are often operations which take 
a length of time observable to the user. For example, downloading 
a file is an operation which can take many ticks to happen, and the 
file value is not available for use until the operation is complete. 

Such operations, which we call “events”, are surprisingly difficult 
to model in a stream-based paradigm, since nothing happens until 
the completion of the process, and once the final event happens, no 
more events occur. Stream-based languages have used a number of 
tricks to encode behaviours like this, but when we have a temporal 
recursive type, it is straightforward to define a type of events: 

E A = (la. A + a 

Here, we simply replace the product with a sum, which means that an 
element of type A is either immediately available, or we have to wait 
until the next tick to try again. (That is, E A ~ A + • (E A). )Events 
make implementing dynamic switching behavior very natural. 


switch :Salloc->SA->E(SA)->SA 1 

switch us xs e [ 1 

let cons(u, 6(us')) = us in 3 

let cons(x, 6 (xs')) = xs i n 4 

case(out e, 5 

ini -ys —> ys, 6 

inrt —> let 6(e') = t in 7 

cons(x, 6 U (switch us' xs'e'))) 8 


In this example, the call switch us xs e behaves like xs until the 
event e returns a stream ys, and then it behaves like ys. 

Events correspond to the “eventually” operator of temporal logic. 
Since the eventually operator forms a closure operator on the Kripke 
structure of times, the event type constructor correspondingly forms 
a monad, whose monadic operations may be defined as follows: 


return : A —» E A 1 

return x = into (ini x) 2 

bind : Salloc —> D(A —> EB) —> EA —> EB 3 

bind us h. e = 4 

let cons(u, 6(us')) = us in 5 

let stable(f) = h. in 6 

case(oute, 7 

ini a —> f a, 8 

inrt-> let 6(e') = t in 9 

into (inr (6 u (bind us' stable(f) e')))) 10 


Here, we perform sequencing by taking a function that maps 
elements of A to B events, and waiting until an A-event yields 
an A to apply the function. Because we do not know when we will 
need to invoke the function, bind requires it to be stable. 

Events are closely related to promises and futures [4, 16], in that 
they are proxies for computations which have not yet completed 
constructing a value. However, unlike most implementations of 
futures, our type E A permits clients to test whether or not the 
computation has finished. Because we embed our events into a 
synchronous programming language, this choice does not introduce 
nondeterminism into our programming language. 

Until Just as the always and eventually operators in temporal logic 
can be merged into the “until” operator, we can also give a combined 
operation for processes that produce values of type A until they 
terminate, producing a value of type B. 

AU B = {lot. B + (A x a) 

Note that streams correspond to producing elements of A until the 
empty type, S A ~ AU 0, and events correspond to yielding units 
until B, E B ~ 1 U B. 

Resumptions The fact that we have function spaces and arbitrary 
recursive types enables us to go well beyond the expressive power 
of temporal logic. In this example, we will illustrate this by showing 
how resumptions [37], a simple interleaving model of concurrency, 
may be encoded in our type system. 

Ri,o A = (la. <x x (A + (I -> O x a)) 

Elements of the type Ri,o A can be thought of as representations 
of thread values, in an interleaving model of concurrency. The left- 
hand-side of the pair a x (A+ (I-)Oxa)) can be seen as what to 
do when the thread is not executed on this tick, and the right-hand- 
side says that either the thread finishes execution with a value of A, 
or it takes an input message of type I and yields an output message 
of type O, and continues computing. 

Given two threads, we can implement a scheduler which takes 
two threads and interleaves their execution until one of them finishes. 


par: S alloc —> R^o A x R^o A —> Ri,o A 1 

par us (pi,p2) = 2 

let cons(u, 6(us')) = us in 3 

case((snd (outpi), 4 

inla—>pi, 5 

inrf —> let 6(pj) = fst (outpi) in 6 

let 6(p 2 ) = fst (outp 2 ) in 7 

let p' = 6 u (par us' p] p 2 ) in 8 

let f'= Ai. let (o, 6(p")) = f i in 9 

into (o, 6 u (par us'p 2 p")) in 10 

into (pinrf')) 11 


One line 5, we see that if the first process pi completes on this 
tick, then the parallel composition completes on this tick. If pi does 
not complete, then we need to return (1) how to defer the parallel 
composition, and (2) the I/O behavior of the parallel composition. 
We construct the deferred computation for the parallel composition 



by taking (on lines 6-8) the deferred computations for each process 
individually, and then resuming their parallel composition on the 
next tick. On line 9-10, we define the function f', which produces 
the same I/O as pi on this tick, defers p2 to the next tick, and then 
on the next tick schedules pz for execution and defers pi’s next 


Definability of Fixed Points Our calculus has a term-level fixed 
point operator fixx. e. However, fixed points are definable, illus¬ 
trating the high expressiveness that guarded recursive types per¬ 
mit. We will show the inhabitation of the type D(«A —» A) —t 
S Alloc —» A, in three steps. First, we define the recursive type 
X = (toe. D(S alloc —> a —> A). We use this type to define the op¬ 
eration selfapp, which takes an element of type X and applies it to 
itself, wrapped around a call to a function f : «A —> A: 
selfapp : (.A —> A) —> S alloc —t X —> A 1 

selfapp f us v= 2 

let cons(u,6(us')) =us in 3 

let stable(w) = outv in 4 

f (6 u (w us'(into (stable w)))) 5 


Next, we can use this self-application function to implement a fixed- 
point combinator. 

fixedpoint: □(•A —> A) —t S alloc —> A 1 

fixedpoint hus = 2 

let stable(f) = h. in 3 

selfapp f us (into (stable(selfapp f))) 4 


This fixed point operator is essentially a variant of Curry’s fixed 
point combinator [11] Y = Af. (Ax. f (xx)) (Ax. f (xx)), with 
extra noise to deal with the modal operators and iso-recursive types. 
The most significant difference is that we need to additionally pass 
in a stream of allocation tokens to ensure that we can construct the 
necessary delay thunks. 


3.3 Blocking Space Leaks Without Ruling Out Buffering 

Our operational semantics makes it impossible to implicitly retain 
values across multiple time ticks, and our type systems statically 
rejects programs which try. For example, if we try to program a 
function which takes a stream and returns that stream constantly, 
then it fails to typecheck, as we desire: 

scary .const: S alloc —» S N —> S (S N) 1 

scary .const us ns = 2 

let cons(u, 8(us')) = us in 3 

let stable(xs) = promote(ns) in —TYPE ERROR 4 

cons(xs, 8 U (scary .const us' xs)) 5 

The reason for this error is that we need to use the argument stream 
at multiple times, and since streams are not a stable type, we cannot 
promote them into a stable variable, which we need in order to use 
the stream value at multiple times. So we get a compile-time error. 

We blocked this function definition because implementing it 
would require potentially unbounded buffering, and we do not want 
to do that implicitly, since that would mean that variable references 
could create unexpected memory leaks. 

However, there are many legitimate programs which need to 
retain data across multiple time steps: for example, we may wish 
to retain data to compute a moving average. Our language does 
not prohibit these kinds of programs; instead, it demands that 
programmers explicitly write all the buffering code. 

As an extreme (and somewhat ridiculous) example, we will write 
the function scary .const, which takes a stream argument and repeats 
it constantly. 

buffer: S alloc —>SN—>SN 1 

buffer us n xs a* 2 


let cons(u, 8(us')) = us in 3 

let cons(x, 6(xs')) = xs in 4 

let stable(x') = promote(x) in 5 

cons(n, 8 u (buffer us'x'xs')) 6 

forward :Salloc —>SN—>«(SN) 7 

forward us xs = 8 

let cons(u, 8(us')| — us in 9 

let cons(x, 8(xs')) = xs in 10 

let stable(x') = promote(x) in 11 

8 u (buffer us' x' xs') 12 

scary .const: S alloc —> SN —> S (SN) 13 

scary .const us xs = 14 

let cons(u, 8(us')) = us in 15 

let 8(xs') = forward us xs in 16 

cons(xs, 8 U (scary.const us' xs')) 17 


In this example, we use a function buffer, which appends a natural 
number to the head of a stream, and then use buffer to define a 
function forward, which pushes its argument one tick into the future, 
and then define scary .const, which repeatedly calls forward to keep 
moving the argument one tick into the future. 

This definition makes the memory leak explicit in the source 
code: our program repeatedly calls forward on the argument stream 
to scary .const, using more memory each time. 

In general, it is possible to define buffering for a recursive type 
(toe. A, if the expression A is constructed from the variable a, sums 
of bufferable types A + B, products of bufferable types A x B, any 
stable type DA, or delays of bufferable types • A. It is not possible 
to buffer arbitrary members of function types A —> B, because the 
environment of a function closure cannot be examined. 

4. Metatheory 

Overview Kripke logical relations have a long history in giving 
semantics to higher-order stateful languages [2, 13, 36]. Since our 
dynamic dataflow graph can be viewed as a store, they are a natural 
tool for showing the soundness of our type system. 

The basic idea behind the technique of logical relations is to give 
a family of sets of closed terms [A] by induction on the structure 
of the type A, each of which possesses the soundness property we 
desire. Then, we prove a theorem (the fundamental property) that 
shows that every well-typed term e : A lies within the set [A], and 
from that we can conclude that the language is sound. 

In a Kripke logical relation, in addition to the type, the relations 
are also indexed by some contextual information, the world, which is 
used to relativize the interpretation of each type. In our setting, this 
contextual information will include the store terms are to evaluate 
under, as well as the permission information telling us whether the 
term may extend the dataflow graph. 

Recursive types make defining relations by induction on the 
syntax of a type difficult, since semantically we expect a recursive 
type to be defined in terms of its unfolding, and unfolding a recursive 
type can make it larger. To resolve this issue, we make use of the idea 
of step-indexing, originally introduced by Appel and McAllester [3], 
in which we extend the world with a natural number n, and interpret 
a recursive type only at strictly smaller numbers. 

In this section, we give a high-level overview of our definitions, 
and a brief tour of the soundness proof. We give the full proof in the 
technical report [25] provided in the supplementary material. 
Supportedness and Location Permutations Before we can de¬ 
scribe the structure of our logical relation, there is one technical 
issue we need to discuss. The allocation rule in the expression se¬ 
mantics is non-deterministic - it chooses a location that is not in the 
current heap. However, the tick semantics cr =)» o', when given 



e C a = free locations of e C dom(cr) 
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cr supported v C cr 
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cr, l : e later supported cr, l: null supported 


Figure 8. Definition of Supportedness 


a nonempty store, removes the most recently-allocated location l 
from the store, updates the older heap, and then updates the removed 
location. The technical question is: what happens if the update of 
the older heap allocates l itself? 

Intuitively, this is not a serious problem, since our allocator 
could always have chosen a different location to have allocated. To 
formalize this intuition, we introduce the idea of supportedness, 
described in Figure 8. We write e C cr if all of the free locations in 
e are in the domain of cr. We write a supported, when every pointer 
containing an expression or value is supported by the heap cells 
allocated earlier (that is, to the left in the list). Then, we can prove 
the following three lemmas. 

Lemma 1 (Permutability). We have that: 

1. If n £ Perm and (cr;e) JJ. then (71(a); 7t(e)} JJ. 

<7r(a');7r(vj>. 

2. Ifn £ Perm and a =$■ cr' then 7r(cr) ==)> 7i(a'). 

Lemma 2 (Supportedness). We have that: 

1. If a supported and eCa and (a; e) JJ- (cr'; v) then v C a' and 
cr' supported. 

2. If a supported and cr => a' then cr' supported. 

Lemma 3 (Quasi-determinacy). We have that: 

1. If{ct; e) 41- (a';v') and (cr; e) JJ. (a"; v") and a supported and 
e C cr, then there is a n £ Perm such that 7t(a'j = cr" and 

2. If a =} cr' and a ==)> cr" and a supported, then there is a 
7i £ Perm such that 7t(a') = cr" and 7r(a) = cr. 

Here, Perm is the set of finite permutations on locations, and 
7i(e) and 7t(cr) lift it to expressions and stores in the obvious way. 
Together, these lemmas imply that we can rename locations however 
we like, and that the nondeterminism of the allocator can only affect 
how locations are named. 

Kripke Worlds We now describe the structure of the worlds we 
use in our logical relation, which we lay out in Figure 9. 

A world w is a triple (n, cr, a). Here, n is a step index, indicating 
that an element of this relation must be good for at least n ticks 
into the future. The term a is a capability. The capability T means 
that we do not have the permission to extend the dataflow graph, 
and _L means that we do have the permission to extend the graph. 
Finally, the store cr must be an element of Heap n , which is the set 
of supported heaps for which the tick relation is defined for at least 
n steps. That is, if a £ Heap n , then there are cri,..., cr n such that 
cr ==)> cri ==)> • • • =)> On. As a notational shorthand, we 
write w.n for the step index of w, w .cr for the store component of 


w, and w.a for the capability of w. We also write 7t(w) to mean the 
world (w.n,7r(w.a), w.a). 

In most applications, step-indexing has been used purely as a 
technical device to force the inductive definition of types to be well- 
founded. In our setting, in contrast, steps have a concrete operational 
reading, corresponding directly to the passage of time: a step index 
of n tells us that the tick relation can definitely tick at least n times. 

Each of these components has an associated preorder <. A step 
index n' is below an index n, if n' is less than or equal to n. A heap 
cr' is below a heap cr, a' < cr, if cr' is an extension of cr - that is, 
if cr' has a larger domain than cr, and agrees with it on the overlap. 
Finally, a capability a’ is below a, if either they are the same, or a' 
is _L and a is T. 

The intuition behind the order on worlds is that w' < w when 
w' is a possible future state of w. In the future of w, we may 
have extended the dataflow graph, or we can potentially receive a 
capability to allocate from our environment. 

The Logical Relations In Figure 10, we define three logical 
relations. 

The set V [A] p w defines the value relation, the set of closed 
values semantically inhabiting the type A at the world w, with 
the parameter p giving the type interpretation of each of the free 
variables in A. The set £ [A] p w gives the expression relation, the 
set of expressions semantically inhabiting the type A (that is, they 
will evaluate to a value of type A if they are run on the current tick). 
Similarly, we also define C [A] p w, the later expression relation. 
These are the expressions that will evaluate to a value of type A if 
they are run on the next time step. 

Both the expression relation £ [A] p w and the later relation 
C [A] p w are defined in terms of the value relation. The expression 
relation consists of closed, supported expressions, which evaluate to 
values in the value relation. Furthermore, the expression evaluation 
may extend the heap only if the world contains the capability to 
allocate. If it does not, then the store will be untouched. 

The later relation C [A] p w is defined by cases. If the world’s 
step index is 0, then we place no constraints on it - it is simply the 
set of closed, supported expressions. If the world’s step index is 
n +1 and the tick relation sends the current world’s store to cr', then 
terms are in C [A] p w if they me in the expression relation of A, 
at step n and store cr'. That is, it consists of those expressions that 
will be in the expression relation on the next tick. 

The value relation is defined by induction on the syntax of the 
type A. Matters first become interesting in the function case. First, 
we require that a lambda term Ax. e inhabiting V [A —» B] p w 
be supported with respect to the heap component of the world. As 
is usual, we quantify over all future worlds w' < w, but we also 
quantify over location permutations n £ Perm. 

Then, we consider all arguments e' coming from the A expres¬ 
sion relation at the permuted world 7t(w'), and assert that applying 
the term to the renamed function should also be in the B expression 
relation at 7t(w'). The extra renaming requirement semantically 
formalizes the idea that we need to ignore the exact choice of names 
(and indeed is very similar to the definition of the function space in 
nominal set theory [17]). 

The later type «A is interpreted as the set of pointers l, which 
point to an expression 1: e later where e is in the later relation of A. 
As with functions, we quantify over future worlds and renamings. 
The interpretation of the stability modality V [DA] p w contains 
values stable(v), where v £ V [A] p (w.n, •, T). That is, these 
values v are not allowed to depend upon the store, or to assume that 
they have the capability to extend the heap. 

Recursive types (la. A are interpreted by the interpretation of A, 
where the environment is extended by the interpretation of • ((la. A). 
Superficially, this looks like a circular definition, except that the 
next-step modality is defined in terms of the later relation for (la. A, 
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Figure 9. Worlds 


which lowers the step index, making the definition well-founded. 
Finally, the semantic interpretation of alloc is the token o, if the 
world has the capability, and is the empty set otherwise. 

Soundness The key property we prove is the following: 

Theorem 1 (Fundamental Property). The following properties hold: 

1. If- h e : A later, then e € £ [A] • w. 

2. If - h e : A stable, then e € £ [[A]] • (w.n, •, T). 

3. If- h e : A now, then e G £ [AJ • w. 

The proof of this theorem follows the usual pattern for sound¬ 
ness proofs by logical relations. We extend the definition of the 
expression relation to define environments binding expressions to 
variables, and then prove by induction on the syntax of the typing 
derivation that all substitutions of well-typed terms by well-formed 
environments are in the logical relation. As usual, a fair number of 
auxiliary lemmas must be proved (such as the monotonicity of the 
value relation, and the stability of all relations under renaming of lo¬ 
cations), and we refer interested readers to the companion technical 
report [25] for details. Once we have the fundamental property, we 
get a soundness property as an almost immediate corollary. 
Corollary 1. (Soundness) If ■ P e : A , then (-;e) ([ (a; v). 
Furthermore, for all n, v G V [A] p (n, a, _L). 

Note that expression evaluation always terminates. This shows 
that our type discipline enforces well-founded use of fixed points 
fix x. e. Also, note that a G Heap n for any n, and so we can tick 
the clock as often as we like. Thus, if we compute a stream value, 
then each time we tick the clock, the tail pointer will point to a new 
cons cell, whose head contains the next value of the stream, and 
whose tail is the pointer to chase on the next tick. 

5. Implementation 

While the work described here is largely theoretical, that theory 
arises from an attempt to understand the correctness of a new 
language, AdjS (the implementation can be downloaded from the 
author’s website), whose type system closely tracks the type system 
of this paper. (The major extensions are polymorphism and linear 
types, and a system to infer uses of the promote(e) operation.) The 
attempt to prove the soundness of the type system was fortuitous: in 
the course of the formalization we discovered two soundness bugs 
in our implementation! 

The first soundness bug was that the AdjS compiler has both 
delay types »A and S A as primitive, but only required an allocation 
token to construct a stream. The second soundness bug was that 
we had originally treated the allocation type alloc as a promotable 
stable type. Each of these bugs made it possible to build a value of 
type □(•A), and use it to access a thunk after its lifetime has ended. 


There remain a few features of the implementation which we 
have not completely formalized. First, the operational semantics 
in this paper forces every thunk when time elapses. Our actual 
implementation is lazier about this, only forcing thunks when they 
are read. It should still be the case that no thunk is forced, except 
on its scheduled tick, but it is additionally possible for thunks to go 
unforced. This is not difficult to model, but it seemed to complicate 
the definition of Kripke extension without sufficient expository 
advantages to compensate. 

More seriously, we have not given a correctness proof of our 
implementation of linear types. While we do have both denotational 
and type-theoretic models of linear guarded types [26], we do not yet 
have a soundness proof of our implementation strategy for it, in the 
same way that this paper shows the soundness of our implementation 
strategy of the functional part of the language. This is because the 
linear types are used to model GUI widgets, and we need a plausible, 
yet tractable, operational semantics for the GUI widgets. This does 
not seem impossibly out of reach, though: recently Lemer et al. [29] 
have given a formal model of the HTML DOM, and we are currently 
investigating using a simplified version of their event model to build 
the operational semantics we need. 

In order to make the synchrony hypothesis (namely, that all 
computations finish quickly relative to the size of a tick), our 
implementation runs at a fixed clock speed of 60 Hz. This does mean 
that the runtime wakes even when nothing is happening. However, 
we do not foresee many issues in increasing the clock speed, since 
Haskell implementations demonstrate that it is possible to sustain 
very high rates of thunk allocation. In contrast, Elliott [14] gives an 
implementation of streams using futures. In our terms, his stream 
type S A is pa. A x E a, where the recursive type is guarded by an 
event constructor instead of a unit delay. This means that each stream 
can run at a different rate, permitting the system to quiesce until 
events become available, at the cost of complicating the merging of 
streams. 


6. Related Work 

Implementing Reactive Programming DSLs for reactive pro¬ 
gramming languages tend to fall into one of two camps. The “purist” 
camp, such as Yampa [35], typically features fairly simple imple¬ 
mentation strategies and limited dynamic behaviour, which fairly 
closely track the semantic model of stream programming. The “prag¬ 
matist” camp, such the Froc library for Ocaml [12], FrTime [10], and 
Scala.React [31], feature more sophisticated implementations based 
on dataflow engines and change propagation, and better support for 
dynamic behavior. 

Now, it has long been recognized that there are connections be¬ 
tween lazy evaluation and the synchronous dataflow paradigm [6], 
but the precise relationship between the two semantics has been 
unclear to date. Our semantics clarifies this connection, by decom¬ 
posing streams into a recursive type over the next-step modality 
of temporal logic. We then show that thunking and lazy evaluation 
can be used to give realizers for the next-step modality, and that 
the synchrony assumption (that is, a global notion of time) enables 
scheduling when these thunks are forced. In other words, we show 
that two standard functional programming evaluation strategies - 
call-by-value and call-by-need - jointly supply all the computational 
primitives well-behaved reactive programs need. 

We can also clarify what parts of the sophisticated implemen¬ 
tations used by the pragmatist languages are necessary, and which 
parts are optimizations. These languages typically work by building 
a graph of dataflow nodes (which might be thought of as a kind 
of generalized spreadsheet), and incrementally recomputing values 
when node values change. The recomputations are guided by the 
dependency structure of the dataflow graph, often using quite so- 
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Figure 10. The Logical Relation 


phisticated techniques: for example, Froc is explicitly based on the 
implementation strategies in self-adjusting computation [1], 

Our decomposition also clarifies the semantics of imperative 
implementation techniques of FRP, by showing how imperative 
state supports a purely functional surface language. Again, the 
decomposition of streams via recursive types and the later modality 
is crucial. Imperative state is essential, since it lets us implement 
the later modality with memoization, and thereby avoid redundant 
multiple recomputations when we reference a later variable multiple 
times. However, persistent state with identity is not necessary to 
implement higher-order FRP, and abandoning it enables significant 
simplifications over the dataflow graph strategy. In a traditional 
dataflow graph, streams are primitives, and represented by dataflow 
nodes with persistent identity. This greatly complicates correctness 
proofs: in [27], we gave such a representation Modeling pure streams 
with dataflow nodes, and were forced to give a vastly more complex 
logical relation to account for the persistence of dataflow nodes. 

Logics of Time and Space To our knowledge, Sculthorpe and 
Nilsson [41] first suggested using temporal logic to verify FRP 
programs. There, they gave a standard (albeit dependently-typed) 
arrowized FRP system, and temporal logic was used to describe the 
behavior of these programs. Jeffrey [19] and Jeltsch [22] were the 
first to suggest using LTL directly as a type system for FRP. 

Jeltsch [21] proposes a design for a Haskell FRP library with 
some similarities with our approach. As in our approach, streams 
are viewed as a kind of generator which incrementally produce 
values. However, instead of using temporal modalities to control 
when streams are used, the types of streams are indexed with 
polymorphic type parameters (“era parameters”) in the style of 
Haskell’s runST operation. Though no correctness proof is given, 
the use of polymorphism suggests that the techniques of Jeffrey [20] 
may be applicable. 

The Modal \i-calculus Our use of recursive types to model tem¬ 
poral operations naturally invites comparisons to the modal p- 
calculus [24]. The p-calculus takes the propositional calculus, adds 
a next-step modality, and adds constructors for inductive and coin- 
ductive formulas. 

The biggest difference is that the p-calculus restricts recursive 
variables to occur in strictly positive position, but places no guarded¬ 
ness condition on those variables. In contrast, our notion of recursive 


type is drawn from Nakano [34], who uses a guardedness condi¬ 
tion instead of a positivity condition, allowing variables to occur 
negatively as long as they occur underneath a delay operator. 

Permitting negative occurrences is extremely powerful: as we 
have seen, term-level fixed points can be defined using recursive 
types with negative occurrences. The definability of fixed points 
in turn means that guarded recursive types enjoy a form of limit- 
colimit coincidence similar to the same property in domain theory. 
In type-theoretic terms, inductive and coinductive interpretations of 
a guarded recursive type coincide. This means that it is not possible 
to distinguish may (coinductive) and must (inductive) properties: for 
example, our event type constructor says that an event may occur, 
but does not say it will necessarily occur. (Recently, Jeltsch [23] 
has investigated potential applications of must-operators to reactive 
programming.) 

Our choice to use guarded recursive types was guided by the 
nature of interactive programs: if we begin to download a file, there 
is no way to be sure that the download necessarily completes (such 
as the wifi may go down). As a result, placing must-properties in 
types is perhaps philosophically arguable. (On a pragmatic note, 
expressing fixed points with guarded recursion leads to very natural 
and idiomatic code.) 

Our stable type DA is not found in the modal p-calculus, but 
may be understood as a constructivization of the always modality. 
When passing from a model-theoretic semantics to a proof theory, 
it is often the case that a single model-theoretic concept bifurcates 
into two or more proof-theoretic concepts. The always modality 
exemplifies this: under a computational interpretation,“always A” 
can either be interpreted as a single value of type A which is always 
available (that is, stability DA), or as a different A on each tick (that 
is, streams S A). 

Very recently, Cave et al. [8] proposed a type-theoretic construc¬ 
tivization of the modal p-calculus (without the DA modality). In 
particular, they use inductive and coinductive types instead of a 
Nakano-style recursive type, and use it to express fairness properties 
(for example, of schedulers) with types. While it is too early to make 
a detailed comparison (larger examples are needed), having calculi 
with both kinds of type recursion available seems like a valuable 
tool for understanding the design space. 

Stability and Permissions Our stability judgment and promotion 
rule are inspired by the mobility judgment in the distributed language 




ML5 [33]. We wanted to identify values we could use at multiple 
times, and they wanted to identity values they could use at multiple 
locations. Promotion is actually definable in our calculus, as a kind 
of eta-expansion. However, operationally these coercions traverse 
the entire data structure, and so for efficiency’s sake we added it as 
a primitive. Allocation permissions were introduced by Hofmann 

[18], to control memory allocation in a linearly-typed language. Our 
observation that in an intuitionistic setting, these tokens correspond 
to an object capability style [32] seems to be new, and potentially 
has applications beyond reactive programming. However, we do not 
yet have a full Curry-Howard explanation of allocation permissions. 
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